Follow-up to #3010 (the fix) and #3015 (the §9 rule). Sweeping for the same anti-pattern — beforeAll(async () => { await import(…) }), which bills a cold module transform to hookTimeout — turned up 36 more test files, every single one already carrying a raised timeout, on an escalating ladder:

That ladder is the finding. Nobody raised a timeout once and moved on — the budgets went 15s → 30s → 60s, which is what "raising the timeout" looks like when it isn't actually fixing anything. One of the 30s files even leaves the escalation as advice: // Increase timeout to 30 seconds for heavy renderer imports.

This PR takes the four highest-risk ones. Each drops its raised timeout rather than raising it again — the import phase is subject to no test or hook timeout.

The four

• plugin-markdown/src/index.test.ts (was 15s) — the twin of the file fixed in test: fix five load-sensitive flaky tests by moving module loads out of timed windows #3010: same shape, same budget, and the same comment verbatim (// Increase timeout to 15 seconds for async import). plugin-kanban proved that budget insufficient by blowing it at 15021ms, and this file's timed portion was already 5.83s of the same 15s. A live flake, not a theoretical one.
• plugin-charts/src/index.test.ts (was 60s) — recharts-backed graph.
• plugin-editor/src/index.test.ts (was 30s) — Monaco.
• apps/console/src/__tests__/public-contract.test.ts (was 60s) — also folds the let contract + hook assignment into a module-scope const, now that the two side-effect imports are evaluated before the module body.

On the console file

This was the delicate one and worth being explicit about. Its assertions pin the eager/lazy registration split (#2953), so the real question was whether moving the imports changes what is loaded when. It does not:

• static imports are evaluated in order, before the module body, so getPublicConfigs() at module scope sees exactly the registrations the hook used to produce;
• the same two modules are loaded, so no extra plugin chunk resolves;
• the shared setup still runs before this module is imported at all.

Its order-sensitive test — "reaches the lazily-registered blocks before their chunks load" — passes unchanged.

Results

Timed portion of each file, isolated:

Full suite is 100% green: 731 files passed / 1 skipped, 8521 tests passed / 24 skipped, zero failures. The unit project alone is 297/297 files and 4084/4084 tests — which also confirms no cross-file interference from the new module-scope registrations, despite that project running isolate: false.

Lint 0 errors (only pre-existing no-explicit-any warnings in untouched test bodies); type-check 38/38 successful. Test-only change, so no changeset.

One note for anyone baselining locally

The ~19 failures this repo can show on a long-lived worktree are a stale install, not a regression: node_modules/@objectstack/spec was 14.6.0 against ^17.0.0-rc.0 declared in package.json. pnpm install --prefer-offline (9s) clears every one of them — which is why the run above is all-green where earlier local runs in this worktree showed 19 failures. Already documented in AGENTS.md §9; flagging it here because it is the single easiest way to misread this suite.

Remaining

The 33-file packages/components cluster (all the same await import('../../../renderers') on 30s) is untouched here — mechanical, but a large diff that deserves its own PR. The durable fix is mechanical enforcement: the repo already has the eslint-rules/ local-plugin infrastructure, and a rule flagging await import(...) inside beforeAll/beforeEach in test files would stop this regrowing. 36 files and a 15s→30s→60s ladder are the evidence that a prose convention alone does not hold.

🤖 Generated with Claude Code